X12 to FHIR System API - Implementation Template
Setup guide
Importing Templates into Anypoint Studio
- In Studio, click the Exchange X icon in the upper left of the taskbar.
- Log in with your Anypoint Platform credentials.
- Search for the template.
- Click Open.
Running Templates in Anypoint Studio
After you import your template into Studio, follow these configuration steps to run it.
FHIR to X12 Converter Application Configuration
The application requires a few things to be configured, mainly the system API connection
information. Configure them in the properties file located in the config/properties
folder.
mule.env
is the environment where the application is to be deployed. For a studio deployment, the recommended mule.env value islocal
.mule.key
is the encryption key for securing sensitive properties.transaction.identifiers.*
are the values that can be customized based on your organizations requirements. See the config file for details.
Please refer to the attached link on how to secure the configuration properties.
API Manager Configuration - Optional
If there is a need to enforce certain policies i.e. security/usage/service, manage the API from API Manager to enable policies for the API. To support this, an entry in the property file is required to bind API Manager proxy with the Mule Runtime deployment using an API ID.
Refer to instructions from link for guidance on applying policies.
api.autodiscoveryId
- sets the API ID from API Manager to bind proxy to runtime.
HTTPS Configuration
https.host
— sets the service host interface. It should be configured inconfig-<mule.env>.yaml
file. (Defaults to 0.0.0.0 for all interfaces)https.port
— sets the HTTPS service port number. It should be configured inconfig-<mule.env>.yaml
file. (Default 8082)- TLS Configuration - Keystore properties setup:
keystore.alias
- sets the alias to the keystore. It should be configured inconfig-<mule.env>.yaml
file.keystore.path
- sets the path to the key file. Key should be available in /src/main/resources/keystore. It should be configured inconfig-<mule.env>.yaml
file.keystore.keypass
— sets keystore keypass to support HTTPS operation. It should be encrypted and configured inconfig-secured-<mule.env>.yaml
file.keystore.password
— sets keystore password to support HTTPS operation. It should be encrypted and configured inconfig-secured-<mule.env>.yaml
file.
Please refer to the attached link on how to generate the Keystore.
Tested and verified
This solution was developed and tested on Anypoint Studio 7.15.0 and Mule Runtime 4.4.0. The X12 connector (v 2.10.0) was used for message parsing
Schemas used for genrating the X12 transaction sets are available within the connector's jar file (x12-schemas- 2.8.13.jar's hipaa folder)
Refer to the documentation here for a complete list of supported versions and transactions.
Assumptions and Constraints
Working with manufactured data sets results in us imposing a few constraints and making certain assumptions on a few segments/objects. Details of the constraints are mentioned below.
1. FHIR Coverage Eligibility Request to X12 270
- HI Segment - Mapped first two diagnosis codes from the first iteration of CoverageEligibilityRequest's item array. Please extend this to cover more diagnosis codes if the data is available and if dictated by the circumstances.
- EQ Segment - Mapped EQ01 to "30", which implies the inquiry is to Health Benefit Plan Coverage more generally, instead of specific type of care inquiry.
- EQ Segment - EQ05 Diagnosis Pointer, following the constraint for HI segment, only one instance of the pointer is set to identify the diagnosis from the first occurrence of an item.
2. X12 271 to FHIR Coverage Eligibility Response
- For each of the 2000 Loops, we are mapping the first occurrence due to the availability of data. Code can be extended to call the same function within a map operator, to create multiple Organization/Practitioners as needed.
- Identifiers for each FHIR resource are created using a generic prefix and uuid(). Replace with identifiers more appropriate for the use case as required.
- Coverage Eligibility Response insurance - Only one insurance is assumed in the X12 271 segment and mapped as an array of one.
- Coverage Eligibility Response item - Mapped EB segment without the instance for EB01=="L", as it is not supported in X12. Refer to comments in provided mapping spec for details.
- Coverage Eligibility Response benefit - Mapped copay as a percentage due to limited data availability. If copay amount is available, code needs to be updated to use allowedMoney too.
3. FHIR Coverage Eligibility Request to X12 837
- BH Segment - Mapped BHT06 to 'CH' (Chargeable) - Use CH when the transaction contains only fee for service claims or claims with at least one chargeable line item. If it is not clear whether a transaction contains claims or capitated encounters, or if the transaction contains a mix of claims and capitated encounters, use CH.
- SBR Segment inside the 2000B Loop - Mapped SBR09 to "ZZ" (Mutually Defined) - Use Code ZZ when Type of Insurance is not known.
- PAT Segment - Ignored the PAT06 - It implies the X12 result doesn't contain deceased datetime.
- PAT Segment - Ignored the PAT07 and PAT08 - It implies the X12 result doesn't contain patient weight.
- PAT Segment - Ignored the PAT09 - It implies the X12 result doesn't contain pregnancy indicator.
Running it
- Right-click the template project folder.
- Hover your mouse over 'Run as'.
- Click Mule Application (configure).
- Inside the dialog, select Environment and set the variable mule.env to the appropriate value (e.g., dev or local).
- Inside the dialog, select Environment and set the variable mule.key to the property encryption key that you used to encrypt your secure properties.
- Inside the dialog, go to 'Clear Application Data' select 'always' radio button.
- In the Arguments tab in VM arguments text area, disable the gatekeeper to test locally using the arguments
-Danypoint.platform.gatekeeper=disabled
. When API Autodiscovery/API Manager configuration are used, gatekeeper needs to be disabled to run the API locally. Refer to documentation here for details. - Click Run.
Deployment instructions for CloudHub using provided scripts
Ensure the Maven profile CloudHub-DEV
has been properly configured in your settings.xml
file. Reference can be found by downloading the Accelerator Common Resources asset. Additional instructions are available in the Getting Started with MuleSoft Accelerators - Build Environment guide.
Update the config-.yaml properties appropriately and then use one of the following scripts to deploy the application to CloudHub:
- packageDeploy.sh or deployOnly.sh (Mac/Linux)
- packageDeploy.cmd or deployOnly.cmd (Windows)
Test the template
- Use Advanced Rest Client or Postman to send a request over HTTPS. The template includes a Postman collection in the
src/test/resources
folder. Update the collection variable(s) after successful import.